An instant messenger (IM) application enables real time communication among online participants. By way of background, an IM application typically includes functionality for allowing an IM user to define a group of participants with whom the user frequently communicates. After defining such a group, the IM application typically notifies the IM user when any member of the group happens to be online. The IM user then has the option of starting a communication session with one or more members of the group. Or the IM user might be contacted by another member who happens to be online. These events prompt the IM application to open a user interface (UI) pane that presents an evolving sequence of textual messages transmitted among IM conversation participants.
FIG. 1 shows an overview of a representative IM system 100. The system 100 includes a collection of client devices (102, 104, . . . 106) connected together via a coupling mechanism 108 (e.g., the Internet). A user Alice (A) operates client device A 102, a user Bob (B) operates client device B 104, and a user Carol (C) operates client device C 106. FIG. 1 shows that client device A 102 provides a conventional user interface pane 110. The user interface pane 110 identifies Alice's “buddies” in a contact list 112, and also identifies whether these buddies happen to be currently online. Assume that Bob and Carol are two members of Alice's contact list 112 who happen to be currently online.
In recent years, providers of IM applications have attempted to provide a more engaging user experience by adding supplemental features to the above-described basic IM functionality. For instance, Microsoft Corporation of Redmond, Wash. has developed an MSN Messenger application that includes various features that exhibit dynamic behavior (such as Messenger's “Winks” feature, etc.). These features may provide an animated vignette for presentation in an IM pane, or other kind of non-static presentation. To achieve this dynamic behavior, such content may contain executable instructions that command the client device to perform operations during runtime. Such content can be implemented in various ways, such as by Flash-based technology developed by Macromedia, Inc. of San Francisco, Calif. Flash movies contain vector-based animation graphics, and may contain script-type instructions (e.g., Macromedia's ActionScript) embedded therein.
However, the incorporation of executable content into an IM application also introduces significant challenges. Namely, there is a risk that a user (or some other entity) may intentionally or unintentionally introduce malicious content into an IM system. For example, instead of merely controlling the presentation aspects of an IM feature, the dynamic component of malicious content may improperly access files, install unwanted code, destroy system resources, activate unwanted user interface presentations, activate webcam or spyware functionality, present unsolicited advertising material, and so forth. Such malicious content may therefore cause great disruption and damage within an IM system, detracting from the otherwise engaging and desirable nature of dynamic IM presentations.
Indeed, while the threat of computer viruses poses a pernicious problem in any computer environment, the consequences of such viruses in an IM system may be particularly severe. This is principally due to the automatic manner in which IM applications propagate information among participants. For example, the propagation of a virus via an Email application often depends on a user taking the express step of activating executable content that accompanies the Email as an attachment. In IM applications, however, it is often desirable to automatically execute such content without the user's approval. A network of interrelated contacts groups might therefore constitute a very susceptible conduit for the rapid spread of malicious content.
Consider, for example, the case in which Alice uses her client device A 102 to retrieve content 114 that happens to have a virus. For example, assume that Alice visits a website that provides a library of animated icons supplied by a content provider. Assume that Alice selects one of these animated icons and downloads it to her local client device A 102 for use in communicating with her buddies. For instance, Alice can adopt the downloaded animated icon as an integral part of the set of information that she provides to her buddies when communicating with them, e.g., such that, for instance, Bob will see Alice's animated icon when conducting an IM session with Alice. However, transfer of the animated icon will also transfer the virus along with it. Bob himself may then further propagate the virus to the members on his contact list, and so on. The reader can readily appreciate that an IM application can therefore rapidly spread a virus through a very large pool of IM users.
The industry has provided numerous tools to reduce the risk of computer viruses. The system 200 shown in FIG. 2 uses an approach that can be said to roughly mirror the way an animal's immune system deals with biological viruses. Namely, the system 200 first identifies the nature of potential viruses in its environments. The system 200 then uses this knowledge as a key to identify the presence of viruses in a content item under review. Upon finding a match between a known virus and a content item under review, the system 200 can quarantine this content item to prevent it from causing damage to system resources and/or from propagating to other systems. Or, if possible, the system 200 can remove a suspect part of the content item, and thereby sanitize it.
To operate in the manner described above, the system 200 requires advance knowledge of the types of threats facing a community of computer users. A virus registration system 202 performs this role. The virus registration system 202 loosely represents an organized approach and accompanying functionality for detecting and registering known malicious content. More formally, the virus registration system 202 monitors a large collection of content 204 for the presence of confirmed malicious content 206, and then registers the malicious content in a malicious content store 208. The monitoring performed by the registration system 202 can take the form of automated and/or manual analysis that detects the presence of malicious content. The effective detection of malicious content also relies on reports sent to the virus registration system 202 by end-users who independently detect viruses in their own systems. McAfee, Inc. of Santa Clara, Calif. is one well-known provider of virus protection services that maintains a large database of known malicious content.
A conventional virus checker 210 applies the knowledge gleaned by the virus registration system 202 to determine whether a particular content item 212 contains objectionable content. Namely, the virus checker 210 employs a virus scanning module 214 which scans the received content 212 to determine whether it contains any of the content registered in the malicious content store 208. The virus checker 210 can quarantine or sanitize content 212 that is identified as potentially unsafe.
As appreciated by the present inventors, services of the type described in FIG. 2 are not well-suited for safeguarding the consumption and propagation of executable content in an IM application. This is because the body of malicious content constantly changes in response to the introduction of new forms of viruses into the pool of possible content permutations 204. Thus, a consumer may encounter a virus before the virus registration system 202 has properly identified the virus and added it to the known malicious content store 208. Since the consumer lacks safeguards against this new virus, the consumer may consume the virus, opening the consumer's computer resources up to whatever damage that the virus may inflict. The system 200 copes with this problem by acting as quickly as possible to stem the further spread of such a virus. This approach—which implicitly accepts a limited amount of damage—may work sufficiently well in the context of conventional communication routes (such as Email). But, as explained above, an IM application is unique in its potential ability to very quickly propagate malicious content among users (without even requiring the active participation of the users). Hence, the “acceptable limited damage” paradigm might not provide satisfactory results for an IM environment, because, in fact, the damage may be neither acceptable nor limited.
For at least the above-identified reasons, there is an exemplary need for more satisfactory strategies for ensuring that executable content will not cause undesirable actions in IM and other applications.